This invention pertains to methods and systems for processing image data.
In the past, printers have typically captured an entire page before any image is placed on paper. In such printers, formatting is either performed on the host computer (with large volumes of rasterized data being shipped to the printer), or on a formatter within the printer. Since a laser printer print engine operates at a constant speed, if new rasterized data is not available at a rate that keeps up with the engine""s operation, a print xe2x80x9coverrunxe2x80x9d occurs and the page is not printable. Various methods for addressing print overrun situations are described in U.S. Pat. No. 5,479,587, the disclosure of which is incorporated by reference herein. Various other aspects of printers are described in the following U.S. patents, the disclosures of which are incorporated by reference: U.S. Pat. Nos. 5,450,562, and 5,459,818.
For purposes of understanding various problems associated with past processing techniques relative to printers and the like, a somewhat high level block diagram describing a system configured to process image data is shown generally at 20 in FIG. 1. System 20 typically includes a so-called image pipeline which processes image data provided by a host into a form which is suitable for use by a printer engine. The image pipeline comprises a number of different elements which can be implemented in any suitable hardware, software, or firmware. In this example, image pipeline 22 includes an interpreter 24, a graphics engine 26, a canvas 28, and an image processor 30. An engine 32 is provided and comprises, in this example, a print engine such as would be found in a laser printer.
Typically, an image or a file gets sent to system 20 via an I/O port (not specifically designated). In a typical personal computer scenario, a print job will load through an operating system such as Windows, to a driver and will be sent out a parallel port. The print job need not, however, come from a personal computer. Rather, it can come from a mainframe, from work stations, or from other devices. In addition, it need not have parallel porting. Rather, it can come through infrared ports or LANs that show other I/O type ports, to name just a few. The print job is received by interpreter 24 which then operates upon the print job in a known manner. At the interpreter level, the print job is parsed and a job stream is formed to determine what operations are being specified. Interpreter 24 is in communication with graphics engine 26 and communicates to the graphics engine what operations are being specified. Graphics engine 26 operates on information received from interpreter 24 by doing such things as ensuring that the information does or does not have to be clipped, Additionally, if a particular structure specified by interpreter 24 needs to be filled, it determines what area has to be filled and the like. If a particular structure specified by interpreter 24 needs to be stroked, it determines what area and what objects are to be used for stroking.
Canvas 28 is provided and is in operable contact with graphics engine 26. The graphics engine 26 sends the resulting object to canvas 28 for processing. The graphics engine 26 communicates to canvas 28 a description of the object it has operated upon. Canvas 28 breaks up information received from the graphics engine into smaller amounts of data. In this example these smaller amounts of data are known as strips. Accordingly, at the canvas level, work requests are built and each work request is associated to a strip.
Image processor 30 is coupled with canvas 28 and will eventually receive the work requests from canvas 28 and start imaging them or rendering them into bits. The rendering of strips into bits results in formation of a raster bit map. The raster bit map is used to drive print engine 32 for rendering an image. The above description constitutes but one exemplary system which can be utilized to process image data into a form suitable for use by a print engine. More detailed information about the operation of systems, such as system 20, can be found in the patents incorporated by reference above. In addition, while the interpreter 24, graphics engine 26, canvas 28, and image processor 30 are shown as discrete elements, such need not be the case.
Problems can occur in the image pipeline because of the different nature of the information or data the elements process. For example, problems can occur at the graphics engine 26 and canvas 28 levels pertaining to the complexity levels at which each element is designed to handle the associated data it receives. For example, canvas 28 works at a fairly low primitive level. Hence, optimal or desirable operation within the canvas functionality is attained when the information or data received thereby is in a very simple format. The graphics engine 26, on the other hand, operates at a fairly high level or in a very sophisticated format. Resultingly, in the translation from the sophisticated format of graphics engine 26 to the simplistic format of canvas 28, one can experience a data explosion.
For example, at the top end of graphics engine 26, one may be directed to draw a circle which is specified by a point and a radius. At the bottom end of graphics engine 26, canvas 28 does not understand that particular definition of a circle, so the circle definition is broken into a number of so-called trapezoids through processing techniques known as polygon decomposition. Accordingly, the circle is broken into n number of primitives. Those primitives can be rectangles, trapezoids, and what are referred to as x and/or y line scans. Hence, a typical circle might break into perhaps 200 or 300 basic objects. This is where a real problem can occur because, essentially, a data explosion results by converting from one format to another.
Prior solutions to the above-identified problems have included compressing raster data across the I/O interface and/or tuning the image pipeline to keep up with existing I/Os, but not placing constraints on the raster image data coming into the printer.
With respect to the compression solutions, such can, in some instances, involve simply taking an image or a page-ready scan, and compressing it with little or no understanding of what device will be used to ultimately process it. In this instance, no optimization is used at all since, simply, a blind compression of the image is conducted which is subsequently sent off to the printer or scanner. Accordingly, the device must then decompress the compressed data and operate upon it to get it ready for the imaging pipeline. Disadvantages to this solution are that to print the raster data at an appropriate engine speed, additional hardware is required at, the data source and in the printer to perform compression and decompression. Additionally, some source images, especially halftoned scanned data can be xe2x80x9cnoisyxe2x80x9d and may not compress very well. As a result, many of these types of pages will not print at engine speed.
With respect to the tuning of the image pipeline without constraining raster image data, such typically involves the device itself getting involved in the breaking of the image into strips, insuring that the data is properly clipped and/or otherwise processed. Hence, every time a pixel is manipulated by the device, the whole system slows down. This can significantly slow throughput. A disadvantage of this approach is that more processing, and hence overhead, is required in the printer to format the data into engine-ready format. A faster printer controller would be needed to keep up with I/O rates of 7.5 MB/sec than what is currently used in some current 32 page-per-minute (ppm) wide-format printer engines.
Accordingly, this invention arose out of problems associated with improving the efficiency with which high-bandwidth image data is handled in a peripheral unit""s, and particularly a printer""s image pipeline.
Methods and systems for processing image data in connection with peripheral units such as laser printers are described.
In one embodiment, an image pipeline is queried to determine at least one constraint which affects the image data provided to the image pipeline from a source of image data. If appropriate, the constraint(s) is imposed on the image data to provide constrained image data. After the constraint is imposed on the image data, the constrained image data is provided from the source to the image pipeline for processing into a page-arranged output.
In another embodiment, image data which is provided by a source is stored in a first buffer. A handle is assigned to the image data. The handle is passed through at least a portion of the image pipeline. After such passing, at least a portion of the image data which was stored in the first buffer is copied directly into at least one strip buffer, with such copying being the first copying of the image data after the storing thereof in the first buffer.
In another embodiment, a peripheral unit for producing a print media having printed matter thereon is provided. The peripheral unit includes a source comprising a query processor, with the source being configured to provide image data describing an image. An image pipeline is provided and is operably coupled with the source and is configured to receive the image data therefrom and process the image data into a page-arranged output. The image pipeline has at least one constraint which affects the image data provided by the source. The query processor is preferably configured to query the image pipeline to ascertain the constraint prior to providing the image data to the image pipeline.